HTML5 安全问题解析

标签： html html5 web安全

本文参考：

w3school:html5相关基础知识（w3school.com.cn）
51CTO的HTML5安全专题
FREEBUFF上有关HTML5的安全文章（FREEBUFF搜索关键词：html5）
相关技术博客和杂文（百度搜索关键词：html5 安全）

文章概要：

html5相关新技术
跨域资源共享（CORS）安全问题
本地数据库注入（Web Sql Injection）
本地存储风险（Local Storage and Session Storage）
js多线程（Web Worker）风险
Web Socket带来的嗅探风险
新标签风险
新API风险

正文：

0x01 html5相关新技术

1. XMLHttpRequest Level 2 (CORS)

XMLHttpRequest主要提供了js直接发送请求的接口，在老版本中有以下缺点：

只能支持文本数据传送，其他数据不可
没有即时进度信息，只有完成与否的状态
不能跨域传输，只能同域内进行传输

在新版本的XMLHttpRequest中（level 2），以上都得到了实现，其中最关键的是可以在服务器和浏览器本身的支持下进行跨域传输。

具体细节请参考：阮一峰的博客

2. 本地存储

在html5之前，本地存储只有cookie（flash cookie）这么一种选择，但是cookie的容量很小，并且安全性上得不到保障。
在html5中，新增了两种存储方式：local storage和session storage，local storage是永久性的存储，大小大概是5MB, session storage时临时的，浏览器关闭即刻清空。其实这两个东西是一个东西，放在内存中是session storage，在文件系统中是local storage。

具体使用方法请见：w3school.com.cn

3. web sql（本地数据库已废弃）

同时，html5提供了本地数据库支持，默认是sqlite这一轻量级的数据库，可以存储一些临时资料或者缓存。

操作方式详见此处

4. web worker（js多线程执行）

由于js时单线程执行的，所以在h5之前，执行js是会阻塞UI的，h5实现了web worker这一机制，从而使得js也可以使用子线程去执行任务从而不阻塞主UI线程了。

操作方式详见此处

5. web socket （服务器推送机制）

由于http时无状态单连接的协议，所以在过去，只能是客户端发送request，服务器响应response，现在h5实现了websocket这一机制，从而可以保持长链接，服务器可以主动推送信息到客户端了。当然需要服务器支持websocket机制。
具体使用方式

6. 新标签和新api

h5新实现了一些比较便捷的标签和api，使得用户对第三方插件的依赖能过有所减少，从而减少不可控安全问题。
比如<video>,<audio>,<canvas>等等。
同时实现了比较多的新的api，比如地理位置api，putstate等等。
具体请查看：w3school.com.cn

0x02 Ajax跨域资源共享（CORS）安全问题

1. 跨域资源请求的方式：

ajax在之前是要严格遵守同源策略的，但是在h5中为了提供更好的使用性，诞生了ajax跨域的方式-CORS。跨域资源共享是为了解决跨域请求的问题的。
除了CORS这个方案，还有另外两种跨域请求的方法，一个是使用jsonp的方式，一个是使用flash的跨域方案，通过服务器上的crossdomain.xml来控制跨域。

2. CORS的做法：

CORS的跨域方式是通过：Access–Control-Allow-Origin这个头以及其他的头来实现的，客户端跨域访问一个服务器，服务器会确定这个这个域名是否有权限来获取资源，若有则返回一个带有Access–Control-Allow-Origin头的response以及资源。若无则返回一个权限错误：XMLHttpRequest cant load .....

3. 风险点：

（1）. 对Access–Control-Allow-Origin设置为*,并且没有携带会话认证，这样子意味着信息被公开在全网。
（2）. http头可以伪造。http可以伪造意味着http头中的域名(origin)可以是假的，所以跨域是要配合身份验证进行的，所以跨域的时候记得带上session id。
（3）. 就算是使用了session id，但是第三方有可能也会被入侵，从而导致源站信息泄露，所以CORS是一个非常危险的东西。
（4）. 内部信息泄露，内部成员打开一个evil website，导致个人会话信息泄露，那么内部网站的数据将会泄露
（5）. 另外，不是设置了Access–Control-Allow-Origin，并且对请求站点做了权限控制，就可以防止信息泄露，在返回权限错误的时候，请求的信息其实已经到了客户端。
（6）. CORS默认不能携带会话信息，但是如果将withCredentials设置为true，则可以携带，所以这个属性最好设置为false。万一需要设置为true，请在Access–Control-Allow-Origin上设置具体的域名，不要使用 *。这是CORS的最后一层遮羞裤了，设置不好就裸奔了。

4. 防御姿势：

不要对Access–Control-Allow-Origin使用 *
要对跨域请求验证session信息。
严格审查请求信息，比如请求参数，还有http头信息。

5. 利用姿势：

CORS主要是提供了一种隐形的跨域数据传输方式，偷取信息用户是不能感受到的，主要是两种利用方式。

第一个是需要将跨域js植入到被攻击的页面，这样子可以劫持到对方的cookie等认证信息。这种方式就是通过一个xss或者sqli，将js植入目标服务器，这样子就可以将认证信息偷过来了，如果是存储型就就更赞了，可以实时更新认证信息。
第二个是将跨域放在自己控制的网站上，通过用户点击来攻击指定由CORS漏洞的服务器。这个要求目标服务器对CORS没有设置好，有CORS配置漏洞。
另外ajax跨域不存在问题了，那么是不是CSRF也可以更隐蔽的进行了呢

6. 参考：

51CTO h5安全专题
 51CTO 文章

0x03 本地存储安全问题

这里的本地存储主要指的是localstorage和sessionstorage。其他的比如windows.history，png cache等等不做讨论。

就如余弦说的，localstorage是大势所趋，因为随着网站的复杂性升级，cookie最多只能有4k，每个网站只能存放30或者50个cookie，这样大大制约了web的发展。所以localstorage和sessionstorage出现了（后面将不分开讨论）。

使用方式：

localstorage使用只能通过js去进行写入或者读取，存放格式为key-value格式，比如localStorage.set("key","value").这个意味着他没有cookie那么安全。

风险点：

js获取，因为是只能通过js设置和获取，导致的结果是不能像cookie一样设置httponly。所以可以配合CORS来获取网站的localstorage的信息。所以localstorage中不能存放敏感信息。
因为在各大主流的浏览器中，除了opera采用base64加密，其他都是采用明文存储的，所以在存储的时候最好在服务器端进行加密。
还有一个，可能会被植入广告追踪标志。

防御姿势：

不要存放敏感信息。
选择合适的域存放合适的信息，比如一次过期的信息就放在sessionstorage中。
对存放在其中的信息最好能够在服务端进行加密。

利用姿势:

配合CORS或者XSS获取本地存储中的数据。

0x04 本地SQL安全问题

H5在之前引入了本地SQL这个东西，但是后面被废除了，他的安全点和后台数据库的关注点差不多，就是要防止在数据中混入sql查询指令。这里不再展开。

0x05 Web worker僵尸网络风险

H5中“解决”了js单线程问题，提出了web worker机制，它为js提供多线程支持，但是多线程带来了一个非常可怕的危险-僵尸网络。

使用方式：

var worker = new Worker("worker.js");
worker.postMessage("hello world");
worker.onmessage = function(){}

风险点：

风险点只有一个，那就是在用户不知情的情况下，使用pc端的资源往外发送大量的请求，如果受控的客户端（僵尸）够多，并且针对某一个目标发送，可以造成应用层的DDOS。（虽然是异域，但是不需要CORS配合，因为CORS只是限制客户端是否能够拿到服务器的数据，而不会限制发送这个事情）
其实这里还有一个postMessage的问题，放到API风险那个小结。

防御姿势：

不要访问不安全的站点
用户注意观察客户端资源占用情况，发现某个页面资源占用反常就关掉。

利用方式：

非常清晰，写一个webworker，然后注入到一些页面中去，只要访问这个页面，web worker就开始工作。

0x06 Web socket 嗅探内部端口

H5的web socket 颠覆了传统的http通信方式（request-response），他通过建立一个长链接，让服务器可以随时推送消息给客户端，而不是采用轮询的方式去做这个事情。

风险点

他是通过开启另外一个非80的端口去做这件事情。从而导致嗅探的可能性。

0x06 新标签带来的XSS风险

H5引进了很多新的标签，比如<video><audio><cavans>等等，具体的可以去w3school查看。
新标签意味着之前指定的xss过滤或者转义规则可能会不适用。

1. 新标签

新的方式如下：

<video onerror=alert(1)><source>
<video><sourceonerror="javascript:alert(1)"
<video src=".." onloadedmetadata="alert(1)" ondurationchanged="alert(2)" ontimeupdate="alert(3)"></video>
<video><sourceonerrorsourceonerrorsourceonerrorsourceonerror="javascript:alert(1)“>
<videopostervideopostervideopostervideoposter=”javascript:alert(1)”>

待补充#todo

2. 新属性

新方式如下：

<form id="test" /><button form="test" formaction="javascript:alert(1)">X
<form id=test onforminput=alert(1)><input></form><button form=test on formchange=alert(2)>X
<input onfocus=write(1) autofocus>

待补充#todo
更多可查看：HTML5 标签安全

0x07 新API安全

1. postMessage

postMessage是web worker中的一个函数，它的作用是主线程给新线程post数据用的，但是有一个问题就是postMessage是不通过服务器的，那么很有可能造成DOM-based XSS。

防御方式
但是postMessage的防御点不在本身，而在onmessage上，onmessage中不能直接使用innerHTML类似的语句添加或者修改网页。

利用方式：

postMessage("<script>alert(1)</script>");
worker.onmessage = function(e) {
    document.getElementById("test").innerHTML = e.data;
}

2. History API

H5在History API新增了两个API：pushState()和replaceState(),这两个方法可以在不刷新页面的情况下添加或者修改历史条目

pushState(data,title [, url])
他的作用是在浏览器历史列表的站定添加一条记录，一个是状态，一个是标题，一个是URL（可选，同域）
replaceState(data,tile [,url])
参数和上一个相同，它的作用是更改当前页面的历史纪录。

利用方式：
可以利用他来伪装GET方法下的反射型xss。
比如，存在一个有漏洞的链接 http://www.foo.com/?a=1，可以进行XSS注入，如：http://www.foo.com/?a=<script>alert(1)</script>

但是如果这么直接写在页面上让用户点击，一般都会发现有问题，所以可以采用短链接的方式，假设上述链接转换为：http://www.foo.com/TqsjW，用户应该会点过去了，但是点过去之后，URL栏中还是原来的长链接，同样会被发现。

但是这么写的话：

http://www.foo.com/?a=<script>history.pushState({},'',location.href.split("?").shift();alert(1))</script>

将他转换成短链接，点击之后，会转换到http://www.foo.com/这个上面，所以就完美的隐藏了。

HTML5 安全问题解析